The invention relates generally to computer-based process execution systems, and more particularly, to the optimized representation of processing logic.
In the earliest days of electronic data processing, jumper wires on plugboards contained the definition of the process a machine was supposed to execute. Humans could not easily read this processing logic contained on the plugboards, and that processing logic represented only a very small and very low-level portion of the rules used to conduct a business enterprise. For example, the entire processing logic contained on a plugboard may have said little more than that numeric values contained in punched cards read by the machine should be summed, but only for those cards having an xe2x80x9cXxe2x80x9d in the first column of the card.
As tabulating machinery gave way to general purpose, stored-program computers, the processing logic moved from plugboards to application programs. The application programs had both machine-readable and human-readable forms. Making the processing logic easily accessible to people, as well as to the computer, was a major advantage over the plugboardxe2x80x94responsible people need to continually create, identify, understand, and maintain the processing logic, and the computer needs to continually execute it.
Processing logic in an application program generally comprises both the functional data manipulations for the computer to perform and the conditions under which those manipulations should be performed. For example, the processing logic may state that under the condition a payment is being made late, then the amount of the payment should be calculated at 103% times the invoiced amount, otherwise the amount of the payment should be calculated at 100% times the invoiced amount.
The ability to evaluate a condition and then determine which, if any, course of action to take dependent on the outcome is known as conditional branching. The computer""s ability to perform conditional branching is a key to its widespread success and its application to problems diverse in nature and complexity. Computer programming languages, e.g., FORTRAN, COBOL, BASIC, and C, provide a variety of means to achieve conditional branching and the sophistication of a programming language may be judged on the conditional branching alternatives it provides. For example, the C language provides IF . . . THEN, SWITCH . . . CASE, FOR . . . NEXT, and other statement constructs for achieving conditional branching. Newer languages, such as C++, are not designed to simplify conditional branching but may include features to further facilitate or refine conditional branching mechanisms. Examples include the private and protected methods of classes in C++ that may restrict the courses of action targeted by a conditional branch.
Regardless of the conditional branching construct used, the purpose is to associate a condition with a course of action. These associations fundamentally represent the processing logic embodied by the application program. Unfortunately, the many possible constructs available for representing these condition-to-action associations obscures their underlying similarity.
The lack of similarity in the representations of the processing logic in traditional programming languages makes it difficult to collect and analyze the processing logic as a whole. For example, a business enterprise may have its manufacturing software, contained in hundreds of individual program modules, written in C, BASIC, and FORTRAN. The same business enterprise may have its accounting software, also containing hundreds of modules, written in COBOL and BASIC. Moreover, the manufacturing software may reside and execute on machines and operating systems from one vendor, while the accounting software resides and executes on machines and operating systems from another vendor. Furthermore, the BASIC language used for accounting programs may be a different variant than the BASIC language used for manufacturing program. Considering the dissimilar languages employed, the dissimilar ways to represent condition-to-action associations within each language, the dissimilar locations where the application programs may reside, and the dissimilar operating systems and hardware, it would be very difficult to programmatically collect and analyze the processing logic contained in all of the manufacturing and accounting application programs together. The same may be true within either of the manufacturing software or accounting software systems, by itself.
So, in a collective sense, the processing logic of the business cannot be readily collected and analyzed with the aid of the computer, despite the fact that the processing logic embodied in application programs is machine-readable. Such analysis of the collective processing logic is highly desirable for performing business modeling and for identifying contradictions, conflicts, and relationships among individual elements of processing logic. Business modeling involves the symbolic representation of the objects, entities, and processes involved in the operation of the business for planning, analysis, modification, simulation, and reporting.
The lack of similarity in the representations of the processing logic in conventional programming languages also has disadvantages despite its being human-readable. At the core of the problem is that fact that the business people responsible for determining the processing logic for the operation of the business enterprise, e.g., supervisors, managers, and directors (managers, or management), generally do not have the technical training required to understand and use computer programming languages. Consequently, management relies on intermediaries, i.e., computer programmers, to translate its intentions into a programming language that the computer understands. For example, if an appropriate company manager decides that a new class of employee needs to be created that earns benefits according to a different set of criteria than other existing classes of employees, then the manager must relate the new criteria to a programmer who modifies an application program or programs accordingly. Besides the inherent delay, this brings with it the possibility that xe2x80x9csomething gets lost in the translation.xe2x80x9d Disconnects frequently result between the business model intended by the management and the business model embodied in the processing logic in the application programs.
One potential solution to the above problems may be to develop software tools allowing management to directly manipulate the application programs written in traditional programming languages. Such a tool could provide an interface that translates between the traditional programming language and some intermediate level of representation more easily understood by managers. Again, because of the diversity of programming languages, a generalized tool would be difficult to develop and any such tool would likely be restricted as a practical matter to particular programming languages, hardware, and operating systems.
Another potential solution to the above problems appears to be standardization on a single computing language within the business enterprise. First, this may not be practical because of a need to use multiple computing platforms, some of which may be incapable of supporting the standard language. Further, the business enterprise may purchase some of its applications from software vendors and have no control over the language in which it is written. Even if standardization is possible, representation of the condition-to-action associations may be dissimilar within the language, e.g., IF . . . THEN vs. SWITCH . . . CASE; and managers are unlikely to have or obtain the technical training required to understand and use the language.
Furthermore, traditional computer languages are targeted for representing only the detailed levels of business processing logic, e.g., the calculation of a particular value to be printed on a particular line of an invoice. The management, however, also generally works with business processing logic at higher levels of abstraction, e.g., the billing of customers with outstanding balances. The high-level abstraction of business processing logic, although integrally related to the detailed levels, is not typically embodied in the application programs of the business enterprise at all. Instead it may be embodied in written or unwritten manual procedures, or in automated scheduling or workflow systems. The automated scheduling and workflow systems may support the storage of rudimentary processing logic in machine-readable form, albeit typically in some proprietary fashion tailored to the specific abilities of the system.
Consequently, there is a need in the art for method, apparatus, and structure for simply and uniformly representing processing logic in terms of its condition-to-action associations, readily susceptible to direct manipulation by persons with limited technical training, and able to simultaneously represent processing logic at multiple levels of detail and abstraction. Such method, apparatus, and structure would have the further advantages of ease of portability and interoperability between and among various makes, models, and versions of computer hardware and operating systems; susceptibility to automated analysis; and support for incremental implementation. Such method, apparatus, and structure would not be limited to applications of business processing, but may be advantageously employed wherever computer-based representation of processing logic is desired. The present invention meets these needs.
The present invention involves method, apparatus, and data structures for representing and executing processing logic using a computer system. The processing logic may be as complex, for example, as the combined practices, procedures, and policies used to run an entire business enterprise, or, as simple, for example, as the process performed by a single machine using an embedded computer.
In the practice of the invention, the processing logic of a subject process is reduced to novel data structures containing its definition. A first data structure stores expressions for evaluating various aspects of the state of the subject process. The expression is a series of symbols that can be evaluated to have a particular value and represents a condition placed on subsequent processing. A second data structure stores information representing correspondences between expression results and tasks to perform. A third data structure stores task definitions. Tasks represent executable responses, i.e., a predefined set of one or more instructions that may be performed using a computer, e.g., a computer program module.
During the operation of the subject process, events occur that are signaled using the computer system. For example, in a manufacturing process, a machine jam may be a type of event that occurs. The particular type of the occurring event, the event-type, is used to identify an expression in the first data structure. The event-type is implicitly or explicitly contained in the input signal. Evaluation of the identified expression produces a resulting value, which together with the event-type, may identify one or more correspondences stored in the second data structure. The identified correspondence information is then used to identify task definitions stored in the third data structure. Execution of identified tasks is then initiated.
In other words, the expressions represent conditions placed on the execution of executable responses, the task definitions define a pool of executable responses, and the correspondences relate the conditions to particular executable responses. By separating the expressions from the executable responses, and relating them via the correspondences data structure entries, the processing logic may be easily reconfigured and existing definitions reused.
In a preferred embodiment, the data structures are maintained as relational tables. The expressions in the first data structure conform to a system of multi-valued predicate logic after the fashion discussed in E. F. Codd, The Relational Model for Database Management, Version 2 (Addison-Wesley 1990). Evaluation of an expression results in a xe2x80x9ctruthxe2x80x9d value, e.g., true or false. In this preferred embodiment, only xe2x80x9ctruexe2x80x9d results produce downstream activity (i.e., only an evaluation of an expression that produces a xe2x80x9ctruexe2x80x9d result has task correspondence entries in the second data structure).
These and other objects, advantages, and features of the present invention will become apparent from the following detailed description when taken in conjunction with the accompanying figures.